Why? 因為你沒有用你的 code 溝通你的想法。
// 可能是 amazon 的運費之類的
var shippingCost = base * rate + extra
// ***********
var shippingCost = (base * rate) + extra
// linter: unnecessary parens
你可能寫過類似下面的 code ,然後被 linter 修改成上面的。
這時候問問自己, linter 是給誰看的?
這理所當然,萬分合理,因為我們想的都是如何優化、如何提高效能,當然都是給電腦看的。
但是你試想,對於同一個問題,有多少種解法?
我們怎麼決定無數個解法之中,哪個解法是最好的?效率最快的?
i++ or ++i 哪一個效能比較好? 如果你知道 ++i 用比較少 register 所以效率好,那麼你要改寫所有 for 迴圈改成 ++i?
或是說,如果有一個 scope 產生的 bug,有可能是電腦解析錯誤嗎?還是人類理解錯誤才會有 bug ?
我們用程式碼來彼此交流想法
我們寫的 code 已經不是組合語言,所以絕對不是「最快的」,
透過抽象化,我們可以用 code 來交流想法,所以無數種解法裡面,如果能清楚溝通
就是好的 code ,能夠清楚理解我們就不用看到每一行 code 都要重寫。
你收到一個商業需求,你花很多時間整理好,寫成code。
寫成能動
大家都會寫,但是你應該是要把 code 清晰地
,讓別人可以理解你整理過
的想法,這才是好的 code。
如果 code 清晰地寫好邏輯,如果有 bug 或是你在寫 code 沒注意到的地方,別人在幫你 review 的時候也能夠快速幫你找到問題或是盲點。
否則,當別人要修改或是未來的自己回來修改 code,那個人又要重新整理一次需求,組織想法,這時候又有時間壓力,他就會說「讓我重寫吧!」
很多類似的數據,反正工程師花最多時間的一定不是「寫 code」
不要寫 write-only 的 code!
也不要拿code寫詩 ⋯⋯ 比如 Perl詩經
抱怨
和老闆溝通,如果你不這樣做,你就會回去之前提到那個「重寫」的地獄。
如果老闆不能溝通,你可以考慮離開地獄。
註:
facebook performance review 中,Initiative 也是很重要的能力,You Know Direction。
所以不要認為工程師不必和老闆、PM溝通。
我的 medium 心得有提到工程師需要的能力,可以跳到中後段
一個簡單的問題
var x = 40;
x++ // (40?)
x // 41
++x // (42?)
x // 42
很多人寫 code 是從其他程式經驗來的,所以這邊很容易可以回答 ++ 運算規則 ,基於 x = x + 1 ,差別是先執行再 +1 還是 先馬上 +1 在執行。
然後,一個 JS最常被抱怨的型別改變問題:
var x = "5";
x = x + 1 // "51" ok,字串相加
var y = "5" ;
y++; //?? 預測應該和上面一樣, 字串相加
y; //??
var y = "5" ;
y++; //5 ????????????
y; //6 ?????????????
這時候發現 y 不如預期時,
抱怨「JavaScript 設計什麼爛語言,垃圾」
但是,回想以前寫 java , c or c++ 有問題,都覺得是自己沒看好文件或是了解不夠深入,
JavaScript 的來源是 ECMA-262 specification
所以有問題先查 specification 看是否符合預期
然後思考:
這邊是 ++ 的 spec,可以發現:
*演算法
一樣,有步驟的*註:演算法,可以想成摺紙的「步驟」
因為很多步驟巢狀疊在一起,所以很多人就 pass 不看了。
這邊抓字面大概看一下
應該是先轉數字
,才做運算。
所以可以思考:
var y = "5" ;
y++; // y 從字串變成數字 5
y; // 變數字後 + 1 = 6
這樣就會和預期結果一樣了。